Network ring topologies are gaining in popularity, particularly in Internet Protocol (IP) networks. Such networks enable carriers to offer large bandwidth to users in a cost-effective manner, since each node in the network needs only two interfaces, rather than having to maintain a separate interface for each of the other nodes as in a mesh network. Ring networks also lend themselves to fast rerouting in the event of network failures, since two alternative routes—in clockwise and counterclockwise directions—are generally available for connecting any two nodes on the ring.
A drawback of traditional ring implementations, such as SONET/SDH, is that one of the directions is designated as the active ring, while the other direction remains on standby for fault protection when needed. In other words, at any given time, all of the nodes in the ring transmit and receive data only in the active direction. Therefore, ordinarily half of the available bandwidth in these rings is reserved for fault protection and is not exploited under normal operating conditions.
Some recently-developed bidirectional protocols provide more efficient bandwidth utilization by enabling data to be transferred between any pair of nodes in either direction around the ring, while maintaining fast protection against faults. The two opposing traffic directions are commonly referred to as an inner ring and an outer ring. It will be understood, however, that in the context of the present patent application and in the claims, the terms “inner” and “outer,” as well as “clockwise” and “counterclockwise,” are used arbitrarily to distinguish between the two opposing directions of packet flow in a ring network. These terms are chosen solely for convenience of explanation, and do not necessarily bear any relation to the physical characteristics of the network.
The leading bidirectional protocol for high-speed packet rings is the Resilient Packet Rings (RPR) protocol, which is in the process of being defined as IEEE standard 802.17. Network-layer routing over RPR is described, for example, by Jogalekar et al., in “IP over Resilient Packet Rings” (Internet Draft draft-jogalekar-iporpr-00), and by Herrera et al., in “A Framework for IP over Packet Transport Rings” (Internet Draft draft-ietf-ipoptr-framework-00). A proposed solution for Media Access Control (MAC—protocol layer 2) in bidirectional ring networks is the Spatial Reuse Protocol (SRP), which is described by Tsiang et al., in Request for Comments (RFC) 2892 of the Internet Engineering Task Force (IETF). These documents are incorporated herein by reference. They are available at www.ietf.org.
Using protocols such as these, each node in a ring network can communicate directly with all other nodes through either the inner or the outer ring, using the appropriate Media Access Control (MAC) addresses of the nodes. Each packet sent over one of the rings carries a header indicating its destination node. The destination node recognizes its address in the header and strips the packet from the ring. All other nodes pass the packet onward transparently around the ring.
When a failure occurs in a link on a bidirectional ring network, packets destined to traverse the failed link on one of the rings must be rapidly rerouted so as to reach their destination via the other ring. This rerouting is known in the art as “protection.” Two schemes are used for this purpose: wrapping and steering. Wrapping, which is the method used in SRP rings, is achieved by looping back the packet stream at the nodes that are adjacent to the failed link. Thus, packets reaching the failed link on the inner ring are looped back to travel to their destination via the outer ring, and vice versa. In this manner, protection is carried out simply by the nodes that are adjacent to the failed link. In steering-based protection, on the other hand, each of the nodes is informed of the failed link. Each node then steers all of its traffic accordingly onto the ring that reaches the desired destination without passing through the failed link.
Wrapping is advantageous in terms of its speed and simplicity, since only the nodes that detect the failure need to carry out the protection function. It is not even necessary to inform the other nodes that a failure has occurred. A disadvantage of wrapping is that the protected packets must travel a much longer path to reach their destinations. The availability of network resources is also reduced, since protected packets travel through all of the segments of the network at least once, and often twice. Furthermore, when the failure is fixed and wrapping is terminated, some packets are likely to reach their destinations out of order, since they can now travel again over their original path, which is much shorter than the wrapped path being used by earlier packets. As a result, wrapping is problematic as a protection mechanism for real-time traffic, such as voice or video, which is sensitive to jitter and packet misordering.
Real-time traffic is therefore better handled by steering, despite the increased complexity of this method. Because steering requires that all nodes be informed and implement the failure protection, its initiation is inherently slower than wrapping. The nodes must be linked by a suitable protection protocol so that they can notify one another of failure conditions. A failure notification packet sent by a node under the protocol must then traverse the entire ring in order to update all of the other nodes. Packets that are transmitted between the time that the failure occurs and the initiation of steering are generally lost. In some data applications the loss of even one packet can lead to an entire frame or block of data being discarded. Therefore, packet losses due to protection should be held to a minimum.
It is thus evident that while wrapping is generally the better protection scheme for block data applications, steering is superior for real-time traffic. Since modern packet networks typically carry both types of traffic, neither wrapping nor steering provides an optimal solution. In SRP, as described in the above-mentioned RFC 2892 (section 3.4), the two schemes are combined by first wrapping and then steering traffic following a failure. In this case, however, the real-time traffic is disrupted twice: first when the failure occurs and wrapping begins, and subsequently when steering takes over, since the steered path is shorter than the wrapped path. Thus, there is still a need for a protection solution that meets the needs of both block data and real-time traffic.